Adrian Mackenzie
Draft version: October 2001
In one important respect, recent ethnographic social studies of technical systems may unwittingly make infrastructure uninhabitable. The greatest virtue of ethnography in the eyes of the social studies of science (or at least, for an important strand of it) consists in the possibility of a symmetrical, relational accounting of persons and things in a given locality (e.g. Latour, 1996). Ethnographic studies strongly co-locate things, practices and people, showing how the effects of purification, mediation and scaling-up associated with contemporary technologies occur. The notion of locality plays a vital role in situating technoscientific knowledges, practices and things. Yet perhaps it leave something too much in place, too unquestioned. The anthropologist Arjun Appadurai suggests that
[d]rawn into the very localization they seek to document, most ethnographic descriptions have taken locality as ground not Figure, recognizing neither its fragility nor its ethos as a property of social life. This produces an unproblematized collaboration with the sense of inertia on which locality, as a structure of feeling, centrally relies. (Appadurai, 1996, 182)
So localizing technical practices and things, for instance, helps us understand the way that 'men [sic] and things exchange properties and replace one another' (Latour, 1996, 61-62), or it may help us understand how 'a person is an effect, a fragile process of networking associated elements' (Law, 1994, 33). But does it also inadvertently presume the existence of a place in which such exchanges, articulation work or networking occurs? If Appadurai rightly says that most ethnographies treat locality as ground, then ethnographies of technical systems might reach a limit here. They could in fact reinforce a sense of inertia which only drives further localization. Unproblematized localization then tempts us to imagine change or innovation as de-racination or uprooting.
Could locality be treated otherwise? Could the inertial, centering effects of locality be counter-balanced by movement, or by the instability of being between-places? A thing, whose name is RAMOSS, exists as I write as a software project in process, a collection of fragments whose coherence cannot be guaranteed either for an ethnographer, or for the engineers and software developers working on it at the Australian Technology Park, Sydney. RAMOSS cannot claim any unusual or obviously singular status. Roughly speaking, RAMOSS is a piece of second-order infrastructure, an operational control system that will control and configure a rural telecommunications infrastructure from a city bunker somewhere in Sydney. Like many infrastructural projects, it dwells somewhere almost lost to sight, embedded deeply in infrastructures and other technological systems that are not widely represented outside the technical worlds and imaginings they inhabit.
During several months spend visiting Forge Research, the company developing RAMOSS, I asked people there 'what is RAMOSS?' An answer that struck me at the time as somewhat vague now strikes me as usefully open-ended and modest:
Umm, ... I guess the whole idea of it is managing these things that they call systems, which are telecommunications hardware. And, umm, there's lots of different things going into that. So basically, we'll be keeping a lot of the information about these systems, ... and making attempts to deal with that automatically rather than needing user intervention. And the company seems to want that more and more. (G., trainee software engineer)
This response points to several things. Firstly, an important contemporary figure - system – appears repeatedly. System talk plays a vital role in the accomplishment of locality. In the ethos of contemporary technical infrastructure the figure of system looms large. It may be time to address, again, what the figure of system does with respect to locality. Secondly, by saying that 'the whole idea of it is managing these things they call systems', it suggests that for the engineer the problem revolves around how to establish coherence amongst things ('there's lots of different things') which may be diverse. It also points reflexively to what an ethnographer struggling to order their materials faces. Finally the mounting desire attributed to the company to automatically deal with information about these things suggests some questions about how desire generates movement.
Appadurai's notion of ethnoscape suggests one way to problematize locality. It melds accounts of multifarious modes of mobility – tourism, migration, education, asylum-seeking, business travel, - with diverse collective imaginations of movement circulating in various media – film, internet, print, etc. The notion of ethnoscape suggests a complex topography cris-crossed by movements of people. But those movements enter into 'mutual contextualisations' (Appadurai, 1996, 5) with stories and imaginings of movement. His specific historical claim, one that I think can be usefully developed in relation to infrastructural things such as RAMOSS, addresses the expansion and proliferation of these interactions between movements of people and the imaginings of movement:
'What I wish to suggest is that there has been a shift in recent decades, building on technological changes over the past century or so, in which the imagination has become a collective, social fact. This development, in turn, is the basis of the plurality of imagined worlds' (5).
People experience themselves as 'between-places' in Appadurai's terms because of this entwining of collective imagining and movement. References to elsewhere permeate the everyday production of locality because collective imaginings have taken on a hitherto unregistered momentum.
In relation to software development, a good description of the mutual contextualisation of movement and imagining of movement, has been provided by Sean O'Riain (O'Riain, 2000). O'Rian's account of Irish software developers convincingly describes the kinds of localities, temporal patterns and disruptions associated with a globally distributed workplace. Yet, like the notion of ethnoscape itself, he focuses almost exclusively on people in movement. Bearing in mind, social studies of technology's interest in accounting for people and things together, without assuming an apriori ontological divide between then, what can be said about technologies themselves? Where does they stand in relation to the 'collective social fact' of imagined movement?
Appadurai also proposed the notion of technoscape to complement the ethnoscape. Technoscape '[is] the global configuration, ... ever fluid, of technology and the fact that technology, both high and low, both mechanical and informational, now moves at high speeds across various kinds of previously impervious boundaries.' (Appadurai, 1996, 34). Some aspects of this definition resemble globalizing accounts in problematic ways. Talk of 'fluidity', and technology 'moving at high speeds' sounds like it might be glossing the production of locality and movement too quickly. With its connotations of effortless movement and fluidity, images and stories of technological speed still magnetize the notion of technoscape. The ethnoscape's mixture of movement and images of movement disappears, supplanted by pure movement.
By contrast, the emphasis on moving across 'previously impervious boundaries' sounds more promising. I am suggesting that if we wanted to problematise locality as ground in accounts of technical systems, an emphasis on how things move across boundaries could be important. Borrowing from the richer notion of ethnoscape, we could ask whether the technoscape displays the same kind of mutual contextualising between movement and imaginings of movement as the ethnoscape. Rather than affirming the speed and power of technical systems to move across boundaries, we might be able to say how the effects of speed and power flow from that interaction.
To place RAMOSS on the technoscape, we need to ask what boundaries it crosses, how it crosses them, and finally, bringing the critical components of ethnoscape to bear on technoscape, how movement and imagining of movement affect it. As part of a national telecommunications infrastructure, the boundaries RAMOSS encounters are geographical, political, legal, and technical. These boundaries appeared in different forms in that local patch of the technoscape surfacing in the office suite of Forge Research, the software company contracted to develop RAMOSS at the Australian Technology Park (ATP) in central Sydney.
Outside the converted locomotive workshops housing Forge, a grassy vacant lot fenced with cyclone wire awaits construction of a hotel by a Japanese developer. Years behind schedule, Andy, the engineering director, reflects one afternoon that building the hotel will mean relocating a telecommunications pit, a kind of local sub-exchange from which telephones lines fan out into the ATP. Since it will manage the telecommunications hardware in just such pits, RAMOSS appears against a geographical and political divide between that vacant lot and the busy Forge office suite, and more broadly between 'bush' and city in Australia. A geographically large but sparsely populated rural periphery lacks the telecommunication infrastructure available in the cities. New digital infrastructures coil around urban centres. However, a political voice can be heard in the city coming with mounting volume from the rural periphery. Like many other places, Australia's agricultural population is directly exposed to world trade and commodity price fluctuations. An explicitly enunciated desire to 'wire the bush', or to roll out digital services to the rural population forms a significant component of Australian domestic politics. If nothing else, digital networks promise instant transmission of the latest fall in grain prices.
The telecommunications company contracting Forge to develop RAMOSS occupies an ambivalent position. On the one hand, on the strength of RAMOSS' functionality, it could publically announce that every telephone subscriber in rural Australia will henceforth have direct access to digital telecommunication services. That would be a powerful card to play in negotiations with the government to provide other perhaps more lucrative services. On other hand, the rural market for telecommunications has few prospects for growth. Rural populations are declining, and further investment in rural infrastructure could be a bad bet. (At any rate, any rollout of new cable across the rural landscape seems out of the question.) Furthermore, the legal status of telecommunications infrastructure itself has entered into a kind of metamorphosis. The telecommunications infrastructure, and especially the copper cable running into remote parts of Australia, dates from the mid-twentieth nation-state monopoly on communication. Now, as the nation-state monopoly is dismantled, what was once public infrastructure undergoes many different kinds of partitioning and carving up through leasing and licensing arrangements. The telecommunications company, whose technical crews once roamed the countryside maintaining infrastructure, is now more interested in outsourcing maintenance and scaling down its rural workforce.
Finally, and perhaps obviously from what I have been saying, RAMOSS feeds into the enormous and large-scale migration of communications across the so-called 'digital divide.' RAMOSS promises to convert an aging yet valuable analog telephone service into a re-configurable, centrally monitored and managed digital network. For the people at Forge, the technical problem of how to move across this boundary looms largest. Most of their imagining, their planning, and their frustrations, stem from that boundary. As it turns out, RAMOSS adopts the kind of solution being developed in many places, and especially in countries where existing infrastructure cannot be totally replaced for economic reasons. RAMOSS will capitalise on existing analogue telephone infrastructure by retrofitting it so that it works digitally. The technique of 'multiplexing' or switching between different signals rapidly on the same line allows it to apparently channel many communications down cables that used to accept only one at a time. Multiplexing increases the capacity of the existing infrastructure at the price of some new complications in configuration and management of the networks. The equipment that multiplexes multiple conversations along one telephone line itself entails distributing a fair degree of computational complexity across the whole telephone infrastructure.
If RAMOSS encounters these kinds of boundaries, how does it moves across them? How does a technical system 'move across' technical, geographical, political and legal/property boundaries? What forms of movement occur? Can we meaningfully speak of technologies moving or being transported? On this point, the question of locality moves back to the fore.
As I have said, RAMOSS seeks to bridge the geographically-correlated analogue digital divide by distributing computational hardware across the existing telephone networks. Near the rural periphery of the telephone networks, new 'cards' (known as RU – Remote Units) will be installed in thousands of roadside 'pits', junction boxes and rural exchanges. These cards perform the one-to-many magic of multiplexing. However, they do so only at a fairly serious cost. Because each card carries an onboard computer, a management problem emerges: how to manage potentially tens of thousands of remote computers, all of them emitting alarms and making requests for data? Each connection that runs through one of these cards will need to be individually configured, and each card will be need to be monitored and regularly attended to. The scale of this configuration work seems almost frightening, given the difficulties associated with reliably configuring even a single computer.
Forge Research must be careful here. Their project concerns a communications infrastructure sprawling, however sparsely, across a continent. The mobility of digital data, the ultimate purpose of the whole ensemble, depends on smooth paths running between the edges of the network and points within it. To make those paths available, RAMOSS must maintain a coherent grasp and representation of tens of thousands of configurable computers. Otherwise the network and its paths will fall apart. I ask the engineering director what he thinks the most risky or unpredictable technical innovation in RAMOSS is. We stand near the kitchen talking. He tells me that the main issue is scaleability. They can be sure that RAMOSS will work here at Forge where they control the conditions, but they can’t be sure whether it will be stand up in the bunker.
Forge has faced the task of building distributed computer systems before. They built an operational support system for a different kind of telecommunications network several years ago. That experience has affected Forge as locality. Forge could be seen as a singular place where certain boundary crossings occur. It could be regarded as a kind of 'between-place' where diverse realities encounter each other. Furthermore, in important respects, it looks like a place oriented towards future migrations or movement across boundaries.
In the context of RAMOSS, the imaginings of movement display themselves in several ways. An early visit to Forge included a tour through the office suite. We visited the server room first of all. The air-conditioning here makes it too cold to work for most people. In the server room, two walls directly index how Forge stages an encounter between diverse realities. On a wall to the west, different kinds of computers occupy racks. Early on in the project, a large crate appeared in the middle of the office suite. It contained a Sun Enterprise server, the kind of high capacity commercial computer that will sit in the control bunker and conduct much of the day-to-day work of RAMOSS. Along the west wall also stand Linux computers which will probably serve as 'satellite boxes'. In network terms that means they lie outside the 'corporate firewall' which prevents unwanted network traffic from permeating into the infrastructure management systems. The wall also includes a rack to hold some RU cards, the hardware which will eventually occupy the pits and exchanges towards the periphery of the telephone networks. Already ranged alongside each other in close proximity, these different computational elements – the Enterprise server, the Linux computers, the RU cards – will have to communicate extensively with each other as RAMOSS develops.
On another wall to the north, the hardware looks very different. Here dozens of plugs, jacks, cables, telephone handsets and small boxes line up. This wall includes a dozen 'primary rate' ISDN (Integrated Services Digital Network) connections into the national telecommunications infrastructure, as well as many standard telephone connections. The wall exposes a series of access points to the national infrastructure which Forge feels quite privileged to have. That degree of access – I hear the team leader say one day, on the telephone of course, 'we are the highest primary rate users in the country' – testifies to the leverage the Forge can exert in creating a locale where things move differently across networks, sometimes crossing 'previously impervious boundaries.'
In the server room we can already see that Forge both turns itself into a miniature version of the national telephone infrastructure, or at least, of some salient facets of it. Yet within this very domain consisting of two walls (another wall is glass, and another has a bookcase with technical manuals and software packages) and some cables, the principal elements remain disparate from each other. In order to affect that infrastructure, and to afford the geographical/technical boundary crossing which the RAMOSS project imagines for rural Australia, those elements must be interlaced with each other. The Enterprise server must listen and talk to the RU cards, passing through the Linux boxes, and the ISDN connections. A telephone handset used near the north wall must be able to call another telephone handset near that wall via the RU cards lining the west wall. These wall, in short, must move closer to each other or be folded into each other, gradually interlaced through a lightweight fabric of code and protocols. Only then, if that interlacing holds here, in this place of dense connectivity, can RAMOSS migrate over to another place of dense connectivity, the control bunker in metropolitan Sydney, or perhaps later, to some other network in some other country.
Already we can see also that Forge as a locality has a peculiar status. The server room constitutes a kind of 'between-place' with respect to the national infrastructure, a place constructed with a view to crossing boundaries. The points and levels of access it has to that infrastructure permits it to invent new ways of moving between parts of the infrastructure. It can elaborate new routes, new loops or new detours from one part of the infrastructure to another. It can introduce new forms of movement or migration through the infrastructure, by for instance, moving chunks of operational code from the Enterprise server across the ISDN networks into the RU cards. While it sounds straightforward, the interlacing of the two walls of the server room isn't. The work done at Forge over months and perhaps years entails a painstaking, minute attention to the fine-grained attributes of the elements loosely stacked in the server room. The work of engineers, developers, managers and technicians brings those walls into contact. Although they read and write between them in ways that always seek to be controlled and predictable in their effects, they cannot avoid immersion in collective imaginings of movement that flow through the very protocols and bodies of code they draw on.
Outside the server room, the two most heavily frequented zones of the office suite are the developer's area and the meeting room. We spent most of our time at Forge in the developer's area observing developers at work. But soon after our visits began, Andy, the engineering director, arranged a session in the meeting room for us. We meet the developers on the RAMOSS project, Andy describes RAMOSS as a system and talks at length about 'Forge process'.
First of all, on a persistently beeping electronic whiteboard, he drew diagrams of telecommunication infrastructure to help explain what RAMOSS would do. The description of RAMOSS as a system was quite involved. Secondly, logging onto the computer and starting a data projector hanging from the ceiling, he began a kind of protracted lecture about 'Forge process.' The lecture at times almost put me to sleep, and at times made me anxious that he wanted mainly convince me that the standard of work carried out at Forge was high. In retrospect, that talk about Forge process now seems more important than it did then when I thought of it as part of a parasitic 'quality management' discourse, or as flowing from Forge's localised micro-vision of modernity. As Latour writes:
People who study technological projects take too little interest in the official doctrines dealing with the actual management of the projects. This metalanguage appears parasitical. Yet it plays the same essential role that strategic doctrines play in the conduct of wars. In the course of a battle or a project, ideas about the way to handle battles or innovations play a performative role. ... Writing a project’s history also means writing the history of the ambient theories about project management. (Latour, 1996, 113)
The diagrams projected onto the wall during the session resembled flowcharts. Boxes and areas, expanded at the click of the mouse, reveal different phases and steps in specifying, designing, modeling, implementing and testing the system. The process has been 'culled out' Andy tells us from the Rational Unified Process (RUP), a mid-90s design methodology that seeks to provide methods, software tools, books, and courses for developing object-oriented software.
The social organisation of engineering work as a project has been described in ethnomethodological studies of engineering:
It is commonplace to refer to engineering projects and the easy way in which this term is used can detract from the recognition that the project is a prominent way in which engineering work is socially organised so as to confront the sorts of contingencies that face software engineering that we have alluded to such as the threatened curtailment because of, for example, drastic slippage, or such as the pressures to abandon good practice. (Button & Sharrock, 1996,372 )
The Forge process, with its complicated itinerary of stages and phases certainly attempted to counter these kinds of exigencies. The threat of cancellation of RAMOSS hovered above Forge. It had already been postponed once before. In addition to this kind of risk management role, with its defensive posture, Forge process generated movement and aligned people and things. Amidst the complications of the Forge design methodology, and all the different kinds of diagrams, syntax, software tools and how-to texts that cluster around it, the important point for the moment might be that process plays a performative role: it triggers a flurry of reading and writing all oriented by the entwined notions of system and process. Adding to this the performative dimension highlighted in Latour's remark, I would say that the social organisation of a project holds due to the artefacts and bodies that embody habits of diagramming, arranging, ordering and accounting for the system.
Latour argues that metalanguages performatively participate in the life of a project. Taking that argument literally, 'Forge process' works as a metalanguage in the RAMOSS project by issuing certain kinds of statements. The effects of these statements do things in RAMOSS' world. Starting out from what appears on the meeting room screen as a general plan or projection of work, and stepping down through all the different projections we saw later at Forge, the performative effect of process talk in general might be understood as repeatedly aligning bodies to work on migrating the projection into other forms of projections, or onto other supports. Disregarding all the details of RUP as a methodology and its local customisation at Forge, Forge process means reading and writing lots of different documents, some of them textual, some diagrammatic, some including code and some not. Documents take shape and move constantly from whiteboard to screen, from screen to server/repository, from repository to screen and then between different zones, windows or partitions on screens. As they move, people work on them and transform them using different tools - diagram editors, text editors, databases, whiteboard markers, foolscap pads . Incessantly, process-oriented speech acts flicker around meeting tables or between workstations. Often, developers draw lists, tables, and boxes connected by arrows on whiteboards, either in the meeting room or near their workstations. While the formal diagram of Forge process does not show how movement between the different phases and stages occur, the unceasing exchanges and co-production of other diagrams fleshes out the abstract process. What happens in that process-oriented team-collective needs explanation.
We could start with the abstract diagram of Forge process projected onto the meeting-room wall. Lucy Suchman and Randall Trigg write:
Like any product of skilled practice, the formalism inscribed on the board leaves behind the logic of its own production and use, seen here as collaborative craftwork of hands, eyes, and signs. But analyses of situated practice ... point to the contingencies of practical action on which logic-in-use, including the production and use of scenarios and formalisms, inevitably and in every instance relies. In this way such analyses provide an alternative to idealized formulations of reasoning as disembodied mental operation (Suchman & Trigg, 1996, 173)
The 'collaborative craftwork' does not move RAMOSS through the phases of Forge process effortlessly. Like all performatives, the process shows uneven traction. Members of the team possess different levels of experience. Some of the trainee engineers still attend university part-time. Their performance of Forge process requires explicit direction from the team leader.
At least until the late eighteenth century, the word 'system' referred mainly to a genre of expository writing concerning with capturing the totality of knowledge within a given field. Only later, and especially during the twenthieth century did the concept of system leave behind its classification as genre of expository writing and migrate towards becoming something, an actual thing in the world (see Siskin (2001)). The definition of RAMOSS I quoted earlier clearly relies on this later understanding. RAMOSS is a system, in fact a system that helps manage these 'things called systems.' What if we roll back our understanding of system to this obsolete sense?
In terms of understanding how RAMOSS gradually takes shape and in accounting for the generative role of process, I think there is good justification to do so. RAMOSS, as its very acronym shows, and like so many other things today, takes shape as a system. The Forge process aims to gradually crystallise the form of a system. Viewed in terms of a genre of reading and writing, what does that mean? The performatives authorised by process attach a certain special significance to some documents. A requirements document, for instance, undergoes intensive reading and writing by a number of different people. During our visits to Forge, we saw the large requirements document for RAMOSS worked on by at least 4 people over a period for months. The highly templated structure of this document was laid down in advance, and various components of the document existed in a database from which the document was dynamically generated whenever it needed to be circulated in an official form. Indeed prior to circulation, an ineditable version of the document was constructed so that no unauthorised or accidental changes could be introduced by different reader-writers. Eventually, a 'sign-off' on the requirements document occurs, and the client and Forge Research contractually bind themselves to that projection of what RAMOSS will be.
Not only the documents themselves, but the people working on them must undergo reformation along the lines of Forge process. New software developers, eager to begin cutting code when they arrive, start work at the same time by learning about Forge process. They spend a month doing 3 days a week on process, 2 days on code. Meetings of the QMS group regularly discuss how process can be refined or streamlined. Frequently, we see and hear developers talking about the status of documents, refining documents, exchanging version information and help on how to manipulate the software tools applied to the documents. The team leader Chris calls out to a developer: “Using flowcharter in Worm, where are the tools?”, meaning 'using the flow charting extensions to Microsoft Word, how does one display a toolbar?'
Different kinds of formalisms – legal, modelling, syntactic, diagrammatic – apply to these documents. Forge process mentions some of them explicitly. 'Computational modelling', an important phase in system design, derives from twin telecommunications industry standards, one called RMODP (Reference Model for Open Distributed Processing), another called TINA (Telecommunications Infrastructure Networking Architecture). Or, drawing more directly on RUP, the Unified Modelling Language (UML) guides the production of 'class diagrams', the object-oriented software models of low-level components of RAMOSS, and 'sequence diagrams', diagrams showing the planned order of events meant to occur when the system runs. The proliferation of formalisms produces large 'documentation trees.' The documentation tree for RAMOSS when we look at it seems vast. Thousands of files have been hierarchically organised, many of them have been generated automatically by software tools (e.g. 'Javadoc', a program that extracts program documentation directly from comments that programmers have put in the source code).
Process stages a kind of unified movement or migration across boundaries. These boundaries might seem artificial, and much less important than the large scale technoscape boundaries mentioned above. They lie between different forms of projection of what RAMOSS will be. Migration from requirement, through phases of modelling, through detailed design to program code entails swapping document formats, switching between different surfaces of inscription (scribbled points on a whiteboard, notes on pad, text documents, model diagrams, program source code, compiled executable binary files, ...). In principle, the migration across these boundaries will be fully controlled, always regulated by the performative effects of process, but as we will see, other voices interrupt that migration, other collective imaginings ripple through Forge.
The system RAMOSS, it might not be too strong to say for the moment, comes out as a side effect of process.i It exists somewhere between the relatively visible projections and descriptions embodied in documents and the jostling icepack of fragments which include software tools, implementations of different communication protocols, network cards, virtual machine implementations, and executable /readable files on Forge's computers. Process seeks to compact those fragments together, and increasingly constrain their movements. At the same time, from the standpoint of that image projected on the wall in the meeting room by the data-project, a central subject position governs and unifies process itself. The team, to the extent that it collectively embodies the effects of the performatives issuing from process, occupies that position.
Two things have emerged. Firstly, we can see Forge itself, and its RAMOSS project in particular, as a fold or wrinkle in the technoscape that 'potentiates' the crossing of certain kinds of boundaries. On the technoscape, RAMOSS begins to trace different kinds of movement across boundaries (city-country, analogue-digital, public-corporate). It moves through an existing infrastructure, the copper wire rural telephone networks, differently. Forge, a kind of between-place that enfolds portions of the infrastructure within its server-room, brings two surfaces, one computational, the other telephonic, into intermittent, flickering contact with each other. A genre of writing called 'the system,' steered by a performative 'process' focused on document generation, organises, describes and projects that contact. Thus, and secondly, system emerges as a side effect of the kinds of controlled migrations elicited by those projections and embodied more or less collectively in the work of the development team.
However vague the outline I have drawn, RAMOSS appears in Forge, which itself lies within the Australian Technology Park. Does the system, stretched between projection and process, or between two different meanings of process, display any of the characteristics of a 'between-place', a place perpetually in movement and incessantly troubled by imaginings of elsewhere? We opened with a question about notions of place and locality. Recent theories of globalisation have tried to articulate a sense of place as somehow 'crossed-out' without being completed 'disappeared.' Appadurai's notion of ethnoscape theorises the crossing-out of place through mutual contextualising movements and imaginings of movement. Does anything about RAMOSS fit that picture?
While we remain at the level of general projections about what happens at Forge, nothing in RAMOSS lends itself to a different account of place. The stages and phases of the project unfurl across the screen in green and blue labelled boxes. Meetings take place where people draw on the whiteboards and conversations around the meeting table inform the writing of new documents. The number of documents grow, and documents gradually change as people work on them. Yet as we move out of the meeting into the developer's area or into the nearby cafe during the mid-afternoon break, something different becomes legible. For instance, walking back from the cafe one afternoon, we pass beneath the large, humming bulk of 'Australia's first commercial fuel cell.' This impressive installation, signposted with a corporate advertisement of Australia's hopes of keeping at the cutting-edge of contemporary technology, supplies some of the electricity that runs Forge's own computers. One of the engineers tells me that the fuel cell causes problems. Computer monitors keep blowing up well before they should in Forge's suite. The fuel cell may be introducing harmonics on the ATP's power grid that blow the computer monitors. In fact, a legal wrangle has developed around it. However, a computer somewhere in Ohio actually remotely manages the fuel cell itself.
The lesson here might be that even something as basic as the power supply, refers to elsewhere. In a much more prosaic fashion, references to elsewhere shoot through the Forge as a locality. They litter the developer's area. The developer's workstations face towards the walls. Mugs, stuffed toys, books, and baseball caps and assorted pamphlets litter the bookshelves above each workstation. These artefacts flag the presence of other places and sites in the developer's workspace. The books, with titles such as Java Enterprise in a Nutshell, come from the crowded computer book shelves of bookshops. On-screen, developers regularly surf their favourite web-sites (e.g. "http://www.slashdot.org") and various online documentation (above all, http://java.sun.com). Just like the souvenirs which constitute little seductions for the computer products they promote (e.g. ORACLE databases, Orbix2000, the JavaOne annual conference), the websites and books constantly consulted by the developers attest to the something important about the fabric of RAMOSS as system. RAMOSS includes or cites many other systems and artefacts. Citations weave through the interlacing of projection and process. Developers, as they 'cut code' for RAMOSS line by line in their chosen IDE (Integrated Development Environment), type statements drawn from template code abundantly littered throughout their workplace in books, help documents and APIs (Application Programmer Interfaces). Cutting code means citing code. Good code can be judged by its legibility in terms of conventions. It cites and plays with the conventions. The development of RAMOSS involves citing and cross-referencing code, design patterns, software libraries, software components, protocols, virtual machines and reference models. Almost nothing in RAMOSS will start out from scratch. Nothing will be totally original.
As media, the toys and documents point towards definite collective imaginings of something. Forge process projects a clear and distinct path of migration through various stages of models, documents and text, provisionally terminating at texts readable by an ultimate reader, a machine. Yet as it folds together the telephonic and computational surfaces of the server room walls, the collective work of the RAMOSS team introduces many switchback turns and layers of 'indirection' along that path. Bruno Latour has described these 'layers of indirection' many times: see [Latour, 1999, **]. Following Latour, we could say 'nothing is technical without detour'. These layers can make the system seem very difficult to understand, even unnecessarily complicated. Citations mark new boundaries in the system. What kinds of indirection or detour come into play?
In terms of the notion of technoscape, these citational practices can be seen as traces of collective imaginings. They come from elsewhere, from the standards committees of bodies such as the World Wide Web Consortium (http://www.w3c.org) or from the Object Management Group(www.omg.org). Usually they arrive via firstly via electronic journal and periodical articles, and then later in the form of the thick computer books published by O'Reilly or Addison-Wesley scattered across developers desks. Finally, standards and protocols flow through into many of the software modules bought in as pre-fabricated components of the system.
Nothing about RAMOSS stands alone, nor could it, given its involvement in weaving together different computational and telephonic infrastructures. As Bowker and Star observe,
In the past 100 years, people in all lines of work have jointly constructed an incredible, interlocking set of categories, standards, and means for interoperating infrastructural technologies. We hardly know what we have built. No one is in control of infrastructure; no one has the power centrally to change it. ... Infrastructure is now the great inner space. (Bowker & Star, 1999, 319)
Infrastructure rarely figures as 'inner space', yet in a very strong sense the protocols, models and standards open a kind of inner space inhabited by developers. During our study, I try to keep track of the many different technical standards and protocols being cited, implemented, or customised in RAMOSS. The list keeps growing, ranging from HTML, XML, Java, UML, CORBA, Linux, Unix, SNMP, MIB, ISDN, , SSL, FTP, TFPT, IDL, DEP, SNMP, IIOP, TCP/IP to POT, to name a few. Many of these standards and protocols refer to other standards and protocols. These entities move across the technoscape just like more visible artefacts and people. They
Day to day work on RAMOSS often consists in grafting together different kinds of protocols and standards, in arranging and adjusting different standards, classifications, protocols and naming schemes so that they hold together. As Bowker and Star go on to discuss, the standards exist as mixed entities, part convention, part physical form. ('All classification and standardisation schemes are a mixture of physical entities, such as paper forms, plugs, or software instructions encoded in silicon, and conventional arrangements such as speed and rhythm, dimension, and how specifications are implemented.' (Bowker & Star, 1999, 39)). More than that, books, tutorials, websites, user-groups, software tools, institutions and communities with complicated histories twine around the standards. We could say, in aligning this very significant component of work at Forge with the notion of ethnoscape, that these mixed entities threaded through RAMOSS amount to collective imaginings, and more specifically, as imaginings of movement. Actual movements of code and data mutually contextualise themselves with these collective imaginings.
In what sense does a protocol or standard constitute an imagined mobility? As Bowker and Star rightly stress, infrastructure has become an inner space, an intensely interlocked domain which RAMOSS must navigate. For instance, RAMOSS must move across different computer platforms and operating systems lining the server room wall (Sun, Microsoft NT, Linux, themselves thoroughly saturated with different standards and protocols) without falling apart. Most people hardly raise an eyebrow at the boundaries between different platforms. At Forge, and in contemporary software culture, such boundaries trigger somersaults in software architecture, and absorb a lot of reading, writing and talking time. The Forge team, on the basis of their previous experience building distributed software software, hope that by embodying appropriate protocols and standards, RAMOSS will vault across the boundaries between computer platform and operating system at two levels simultaneously. Firstly, by coding in Java, a cross-platform programming language, they give a RAMOSS a runoff to jump between machines more easily. Secondly, by coding certain external features of the system to the CORBA (Common Object Request Broker Architecture) standard, RAMOSS should be able to interface even with software not written in Java or, more accurately, running as a process in a Java Virtual Machine.
Two major consequences flow from CORBA's presence in RAMOSS. Firstly, CORBA necessitates heavy configuration work which must grapple with possible 'decontextualisations' of the system. Secondly, as RAMOSS embodies elements of CORBA, it becomes more openly citational.
As to the first, the team grafts the different hardware configurations onto each other using a labile combination of software tools, books, websites, telephone helplines, downloaded documents and experience more or less collectively accessible in the developer's area. Sometimes, when serious obstacles thwart their movement, and all the tricks, 'workarounds' and 'clean cuts' have failed, expertise comes in from the outside. Especially when it comes to configuring products that Forge has purchased as pre-built components, the team experiences configuration work as a risk and frustration.
They, for instance, purchase a software product called IONA OrbixWeb to use as a central component in their moulding of RAMOSS to the CORBA specification. They buy OrbixWeb because every system compliant to the CORBA specification needs to have a running ORB (Object Request Broker) accessible to each and every 'process' involved. Initialising the ORB so that local and remote machines can find and communicate with it can be complicated. Even apart from all the design work needed to implant CORBA in RAMOSS (as we will soon see), just starting IONA OrbixWeb reliably on different computers proves difficult. Bryn, one of the more experienced members of the team, has not managed to configure Orbix on a Linux machine. A heavy pile of IONA manuals stand on his desk. Several days later, he manages to initialise the ORB on a Sun machine. He has modified the configuration scripts that come with ORBIX to work in his local environment. Sometimes, however, Orbix does not start reliably. A stream of errors or 'exceptions' rolls down the screen. Today, after a number of phone calls over the last few days to a help line, a consultant from IONA visits Forge to help stabilise the configuration, and to make starting Orbix reliable. Configuration work involved in running different computational processes together generates coherence for the system, yet also remains a perpetual risk. Configurability, something that Forge also prides itself on, means that even though RAMOSS in this case probably resides on 'one box', the server in the bunker, the underlying design presumes the system will be distributed across different 'processes' or 'boxes.'
Secondly, a tracework of boundaries, cuts, ruptures and decontextualisations pervade RAMOSS as it gradually cross-hatches itself into the technoscape. Citational practices necessitate them. The team leader describes the general distributed architecture of the system to me one day:
Well there are components called distributed processing components, and they form a distributed processing environment. Now at the base of that you've got such things as the ORB, CORBA, but above that you meet such things as cluster managers where you're clustering these computational elements together ... [into] what we call a cluster which is really a capsule in RMODP terms, and a capsule can contain multiple clusters. But we decided early on that we couldn't see the advantage of having capsules outside clusters so we just ignored clusters. ... So you have to have something to manage those, you have to have something to manage the clusters, which is what we call a node manager. You need to have things called traders for finding what resources and services, you need notification services which allow you to forward events between different processes. They are all distributed processes which help to make the environment work.
The Common Object Request Broker model contained in the CORBA specification imports tropes of brokerage, trading, services, leases and transactions into RAMOSS. The incorporation of different models, standards and protocols means that the system takes on an open yet highly interlocked texture of different metaphors or tropes. A specific kind of designed openness appears. Elements of the design, such as the division of the system into different software 'services' (broker, trader, notification, management), instantiate features of different models, standard and protocols. So, for instance, a particular 'BusinessManager' component in RAMOSS which manages user requests for information about the status of a particular RU card might at another level of the design need to be coded in a way that complies with CORBA. A detailed design must be specified for the BusinessManager in IDL. IDL, the Interface Definition Language, provides a way of describing different types of objects and how they interact with each other over networks. Even if the core system of RAMOSS lives on one machine in the bunker, its design contains many different internal boundaries and divisions (between components, between services, between clients and servers, etc.) which could potentially open out over a greater distance.
Reading the specifications of the CORBA standard (see http://www.omg.org) would keep not many people awake at night. Yet the seductiveness of certain models, protocols and specifications as collective imaginings should not be underrated. I watch another software developer, Graham, at work on implementing some of the screens that technicians in the bunker will see. He types XML code into an editor. XML has attracted a lot of attention as a potential successor to HTML. Covers of computer magazines and periodicals, dozens of web-sites, and a large number of specification and 'how to' articles have promoted XML over the last few years. They fixate on the idea of flexible layout: different devices or application can display the same XML code in completely different ways. HTML, by contrast, specifies layout on a screen once and for all. I ask him why they chose to use XML? He tells that most There was an example at Apache, but it was too inflexible. So the code he writes will 'have more loops in it', but should be more flexible. Flexibility, extensibility, mobility and the capacity to 'scale up' exert powerful attractions on the cultures of software development, even if they do bring layers of complication.
Diarmuid, a telecommunications engineer, tells me about the problem of scale, and how Forge, in developing systems like RAMOSS, deals with it:
Well the biggest issue we always had was just sizes, for instance, of tables. I mean as the Internet’s obviously discovered, as the number of units in it grow and grow, protocols which handle the exchange of large tables for instance, become unworkable. I mean, one thing’s shipping around a hundred entries, another thing’s bouncing around 10,000 entries ... But the biggest consequence of most of what we used to come across was a lot of organisations didn’t sit down and think about a naming structure, a naming hierarchy, and even an addressing kind of hierarchies. So that eventually you had so many units out there which just got out of… you couldn’t actually keep the data, in the systems, integrity aligned. You know, they did silly things. Like… in the smaller systems you get away with it, you could maybe embed an address or something into a device. But once you went into large scales and redundancy, where large systems could communicate with other systems which might have completely different addresses, you couldn’t have these things embedded.
His comment about the problem of protocols points to the difference scale makes, and in particular how different densities or concentrations of data destabilise a system ('bouncing around 10,000 entries' Vs 'shipping a hundred').
To summarise, recall that at the outset I cited two critical points from Arjun Appadurai's work on globalisation and modernity. These points counter pre-critical understandings of the conditions of possibility of contemporary technical mediations. The first concerned the role of locality as ground in ethnographic studies. Appadurai argues that processes of localisation enrol most ethnographers into an 'unproblematised collaboration' with locality. As they seek to document the production of locality, they also reproduce it. Locality becomes ground not figure. The second point, following the first, twinned the notions of ethnoscape and technoscape. The notion of ethnoscape works against the ethnographic collaboration in production of locality by focusing on a kind of contrary motion between people in movement and collective imaginings of people in movement. Against an homogenising globalism of movement, it describes a complicated even turbulent confluence of mobility and imagined mobility. If technoscape focused more on these kinds of contrary motion, it could, I hope, do something similar in dislodging contemporary infrastructural things from their place. Perhaps Latour meant this when he wrote: 'a technological project is not in a context; it gives itself a context, or sometimes does not give itself one' (Latour, 1996, 133). Rather than localising things, rather than seeing that things stay in place, it would begin to open onto a between-place, a strange place where having to move becomes more like a second nature.
Movement on the technoscape today particularly involves genres of writing known as systems in complex migratory patterns across boundaries. What orients that migration? Boundaries marking differences – geographical, political, legal, technical – run around the edge of contexts. During his magically orchestrated Aramis, Latour wrote about alternatives to 'putting things in their context':
What this requires is not to “replace projects in their context,” as the foolish expression goes, but to study the way the project is contextualized or decontextualized. (Latour, 1996, 133)
In Aramis, contextualisation and decontextualisation hook up and uncouple a 'project' from other events, things, and people. With this orientation in mind, we could say boundaries eventuate and disappear, become impermeable or porous, as a result of the connections established by a project.
Harder to accept, yet strongly visible in the RAMOSS project at Forge, contextualisation and decontextualisation occur together at the same time, not alternately or at loggerheads with each other. The server room at Forge poses a topological problem. It tries to locally pinch the technoscape so that telephone and computer can be coupled. The pinch slips constantly, not because of any lack of expertise on the team's part, but due to the 'between-place' they occupy. Process, project, and system circle round each other, alternately enabling and restricting movement. Collective imaginings of mobility, embodied in standards, protocols and specifications, themselves embedded in software, tools, documents and websites, fashion new boundaries and obstacles. Through the attraction they exert on the team, the imaginings trouble the smooth translation across boundaries. They induce detours, torsions and convoluted trajectories. The configuration work done by the team multiplies. Multi-layered and distributed designs result, with all the attendant complexities of documentation, diagramming and implementation. The processes of contextualising and decontextualising take on a very fine grained composition in that patch of the technoscape that surfaces in Forge.
Recent theories of globalisation suggest that we need to get used to moving between places, or being in 'between-places'. Social theorists such as Ulrich Beck speak of having to keep finding one's place as a kind of second nature:
What is coming to the fore is the inner mobility of an individual's own life, for which coming and going, being both here and there across frontiers at the same time, has become the normal thing. (Beck, 2000, 75)
Strange mixtures of necessity and desire animates this movement. Many theories of globalisation still tend to place contemporary technology (especially information and communication technology) on the side of necessity, as a force majeure, as a free-wheeling juggernaut, homogenising or decontextualising places and locales wherever it goes. Whereas more nuanced accounts of globalisation don't show this tendency in relation to politics, finance, migration and media, a globalist undertow drags on their relation to technology. Against that tendency, and through an ethnographic study of a piece of information infrastructure, this paper asks how the mixed necessity and desire to move also affects technology itself.
Science and technology studies offers ways of engaging with accounts of globalisation. It should counteract tendencies towards 'globalism', just as it has resisted universalist or idealist accounts of the epistemological authority of science. It can directly counter globalisation talk that treats 'technology' as a neutral monolithic substrate of movement. The symmetry-restoring effects of rhizomatic actant-ontology can, for instance, help bring the figuring of locality into focus. My reservations stem from recent critiques of ethnography, and the ongoing re-alignment of what in principle constitutes the task of ethnography today. Ethnography has relied on notions such as locality, situation, place and boundary to ground its work. Today, what figures in situation, places, and things except cross-hatched references, or the ingression of elsewhere?
References
A. Appadurai, Modernity at large: cultural dimensions of globalization, (University of Minnesota Press Minneapolis, 1996).
U. Beck, What Is globalization? tr. Patrick Camiller (Cambridge: Polity Press, 2000)
G.C. Bowker & S. Leigh StarSorting Things Out. Classification and Its Consequences, (MIT Press, Cambridge MA, 1999)
J. Law, Organizing Modernity, (Blackwell, Oxford New York, 1994)
B. Latour, B. Aramis, or the Love of Technology, tr. Porter, C. (Harvard University Press, MA, 1996).
B. CantwelI Smith, The Origin of Objects (MIT Press Cambridge, Massachusetts London, England 1996).
B. Graham & W. Sharrock, 1996 'Project Work: The Organisation of Collaborative Design and Development in Software Engineering' Computer Supported Cooperative Work: The Journal of Collaborative Computing 5: 369-386, (1996)
L. Suchman, Lucy A. & R. Trigg “Artificial intelligence as craftwork” in Understanding Practice: Perspectives on activity and context, (Cambridge University Press, Cambridge, 1996)
S. Ó Riain 'Working for a Living Irish Software Developers in the Global Workplace' Global ethnography Forces, connections, and imaginations in a postmodern world, ed. Michael Burawoy . (University of California Press, Berkeley and Los Angeles, California, & London, England, 2000 )
D. Flanagan, J. Farley, W. Crawford, & K. Magnusson Java Enterprise in a Nutshell. A Desktop Quick Reference, (O'Reilly & Associates, 1999).
i In his orientation presentation, Andy spoke of systems and process together. The coupling between these terms runs fairly deep, and isolating one from the other I think would be impossible. Systems, at least in the usual sense of the world, exist as and consist of processes. A system unfurls temporally as process. While the developers will gradually write and re-write RAMOSS as a program, a somewhat static description of a projected thing in the world, a program ultimately becomes a system only by becoming a process. But that ultimate event, when a program fully transubstantiates into a system, may not arrive for a long time and perhaps not ever. In the meantime, RAMOSS as a system stretches between something loosely called 'Forge process' and the somewhat more fragmented 'processes' that run on various developer's workstations and on the Enterprise server as different components of the systems are coded up and tests. (Even then, it will inevitably have to be configured and run on some kind of processor, even if that processor only simulates the real hardware on which RAMOSS will run when installed in the control bunker.) Forge process regulates the production of a set of more or less fine-grained written projections that visualise what the system will be. RAMOSS as a system increasingly embodies processes that, in terms of the topography of the server room, get the walls talking to each other. But this 'meantime' or middle period of the system, when projection and process circle around each other, interacting and exchanging attributes, will consist of innumerable iterations. Even after 'release', when the system runs in the control bunker and lives amidst the networks, a final and full coincidence between projection and process would be an ideal whose realization is ever-deferred.